In organizations processes are described by comprehensive process designs. A business process is a set of coordinated activities, conducted by both humans and technical resources, with the objective to achieve a specific goal. Process designs are represented as process models in a particular modelling language, usually depicted by a graph of activities and their causal dependencies.
Besides a documentation of existing processes, the design of process models may have several, additional motivations that can be clustered into motivations that accomplish the organizational design or the development of information technology systems. Process descriptions support process design by enabling the identification of flaws in existing processes, by optimizing and by monitoring existing processes. Concerning the design of an IT-Infrastructure, process models play a vital role for the specification and configuration of software systems. Another important role denotes the usage for workflow management systems wherein process models specify executable workflows.
Hence, process models are input for semantic analysis activities that address organizational or information technology aspects. Semantic analysis activities comprise the comparison of process models, the calculation of process model metrics, the extraction of a common sense process vocabulary and queries on process models.
The comparison of process models is a semantic analysis activity which addresses the identification of similar or equal process activities in process descriptions. Model comparison can be used to specify a metric that defines a similarity measure between reference processes and organizational specific processes, for example. Reference processes describe common or best practice process solutions. Further, the comparison of process models enables to identify structural analogies in process models that may be an indicator for process patterns.
The calculation of process model metrics is performed to calculate model metrics which can be used to determine a process model quality by calculating a measure that determines the complexity. The model complexity can be defined by a number of logical connectors, a number of different activities, relationships between input and output objects, or a number of different roles associated with process activities.
In large organizations, the design of process models is realized by a number of process modelers. This implies a certain subjectivism concerning the naming of activities and information objects by using synonyms, not standardized abbreviations, for example.
Queries on process models enable answers to question such as:                Which activity is triggered by a certain event?        How is an activity decomposed into sub-processes?        Which roles are involved in a certain activity?        What is the required input, the delivered output of a process activity?        What are the preconditions necessary to perform a specific activity?        
Such semantic analyses of process models can be conducted manually by human experts or can be performed automatically. Automated semantic analyses require a machine-readable process description with a formalized semantics of the model structure, the process elements and its descriptions.
One of the most popular process modelling language denotes the Event-driven Process Chain (EPC) modelling language. It has gained a broad acceptance and popularity both in research and in practice. An EPC Model is a directed and connected graph whose nodes are events, functions and logical connectors which are connected by control flow arcs. Functions represent the time and cost consuming elements by performing tasks on process objects (e.g. the task “Define” is performed on the Process Object “Software Requirements”). Each function has exactly one ingoing and one outgoing arc. Further, a function transforms a process object from an initial state into a resulting state captured by events that represent the passive elements. The state information is also bound to a text phrase (e.g. “Requirements Defined”). Each event has at most one ingoing and at most one outgoing arc. A connector can be either an AND-, an OR-, or an XOR-connector. A connector has multiple ingoing arcs and one outgoing arc (join), or it has one ingoing arc and multiple outgoing arcs (a split).
Conventional EPC model can be annotiated as follows:
N is a set of nodes and A⊂N×N is a binary relation over N, the arcs. Each node nεN has a set of ingoing arcs
nin={(x,n)|(x,n)εA} and a set of outgoing arcs
nout={(x,y)|(x,y)εA}.
An EPC Model is formally defined by a tuple M=(E, F, C, l, A, n, id) consisting of                three pairwise disjoint sets E (Event), F (Function), and C (Connector),        a mapping |:C→{and, or, xor) and        a binary relation of control flow arcs        A⊂(E∪F∪C)×(E∪F∪C) such that                    |ein|≦1 and |eout|≦1 for each eεE,            |fin|=|fout|=1 for each fεF, and            either |cin|>1 and |cout|=1 or |cin|=1 and |cout|>1 for each cεC                        a function n:(E∪F)→String that is the name for an event or function        a function id:(E∪F)→Integer that is a unique identifier for an event or function        
The following sets of connectors are defined:
Split Connectors:                Cas={cεC|l(c)=and |cin|=1}        Cos={cεC|l(c)=or |cin|=1}        ×Cxs={cεC|l=xor |cin=1}        
Join connectors:                Caj={cεC|l(c)=and |cout|=1}        CoJ={cεC|l(c)=or |cout|=1}        ×CxJ={cεC|l(c)=xor |cout|=1}        
Further, EPC models consider the following additional syntactical restrictions:                each EPC starts and ends with one or more events,        an EPC contains at least one function,        an EPC can be composed of several EPCs,        an event cannot be the predecessor or the successor of another event,        a function cannot be the predecessor or the successor of another function,        each OR-split and each XOR-split connector should be preceded by a function,        there should be no cycle of control flow that consist of connector nodes only.        
FIG. 1 illustrates an example for a conventional EPC model. It consists of seven EPC-Events and five EPC-Functions whose control flow considers the following split connectors: one “or” one “and” and one “xor”, and the following split connectors: one “and” and one “xor”. The EPC-Function with the ID “03” is named with by the string “Define Software Requirements With Customer”. Further, the model has two start events, namely “software Project Authorized” and “Customer Received”. This means, that the succeeding functions will be executed if at least one or both of the two events occur. This logic is implied by the “or” join connector. The model concludes with the end event “Software Development Project Planned”. This means that the described process achieves the state “Planned” for the process object “Software Development Project”.
Using conventional EPC models for process descriptions as a basis for automatable semantic analysis activities faces one significant problem. EPC models are semi-formal process descriptions. This means that the implicit semantics of names for EPC-Functions and Events is bound to natural language expressions. The EPC modelling language suggests naming conventions or guidelines that specify the syntax for text clauses used for naming EPC-Functions and Events. Main objective of naming conventions is to specify syntactical rules that must be complied in order to reduce the subjectism of process modelers. Thus naming conventions care for a standardization regarding the naming of EPC-Functions and Events.
Hence, semantic analyses of EPC models require to resolve in a first step the meaning of names that can be understood by a computer. Resolving addresses the identification of relevant process information and its associated meaning implicitly captured by a name. To achieve a unique meaning of the names that describe EPC-Functions and Events, they can be semantically annotated. Semantic annotation links each EPC-Function and Event to entries of a process knowledge base that captures the semantics of used names.
As a further example “Define Software Requirements with Customer” is a possible name for an EPC-Function. This name consists of the task “Define” that is performed on the process object “Software Requirements”. The process object “Software Requirements” is a specialization of the general process object “Requirements”. The process object “Customer” indicates a parameter for that task, since this task is performed in a cooperate manner with a customer. If the name would be “Define Software Requirements for Customer” then the parameter has a different meaning since the customer indicates the target of the performed activity.
A conventional process for semantic annotation of EPC models neglects the implicit semantics of EPC functions and events.
It is an object of the present invention to provide a method and an apparatus for an automatic semantic annotation of a process model considering the implicit semantics of named process elements.